System and method for managing medical databases for patient care devices

ABSTRACT

A system and method for creating, managing and loading selected configuration datasets used to program a patient care device to have a selected behavior is provided. A common configuration database includes medical treatment guidelines and device operating characteristics for a plurality of patient care device types. A processor operatively connected to the configuration database is programmed to construct at least one device-specific configuration dataset for a selected device behavior from the common configuration database and load the device-specific dataset into the memory of a patient care device. Further, the device-specific configuration datasets may contain device communication information, including communication protocols and data structures, for a plurality of patient care devices types and behaviors to enable communication between patient care devices.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.10/902,989, filed Jul. 30, 2004, and currently pending, the entirety ofwhich is incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates generally to systems and methods formanaging patient care in a health care facility, and more particularly,to systems and methods for creating, managing and a universal,user-specified configuration database for the purpose of customizing thebehavior of a plurality of diverse patient care devices.

BACKGROUND OF THE INVENTION

Medication errors, that is, errors that occur in the ordering,dispensing, and administration of medications, regardless of whetherthose errors caused injury or not, are a significant consideration inthe delivery of healthcare in the institutional setting. Adverse drugevents (“ADE”), defined as injuries involving a drug that requiremedical intervention, and representing some of the most seriousmedication errors, are responsible for a number of patient injuries anddeath. Accordingly, healthcare facilities continually search for ways toreduce the occurrence of medication errors.

Various systems and methods are being developed at present to reduce thefrequency of occurrence and severity of preventable adverse drug events(“ADE”) and other medication errors. In the administration ofmedication, focus is typically directed to the following five “rights”or factors: the right patient, the right drug, the right route, theright amount, and the right time. Systems and methods seeking to reduceADE's and PADE's should take these five rights into consideration.

In many hospitals and clinical laboratories, a bracelet device havingthe patient's identification, such as his or her name printed thereon,is affixed to a patient upon admittance to the facility in order toidentify the patient during his or her entire stay. Despite thissafeguard, opportunities arise for patient identification error. Forexample, when a blood sample is taken from a patient, the blood samplemust be identified by manually transcribing the patient's name and otherinformation from the patient's identification bracelet. In transferringthe patient's name, a nurse or technician may, instead of actuallyreading the patient's bracelet, miscopy the name or may rely on memoryor a different data source. Moreover, manually transferring otherinformation such as parameters for configuring an infusion pump todispense medication may result in errors that reduce the accuracy and/oreffectiveness of drug administration and patient care. This may resultin an increased duration of treatment with an attendant increase incost.

Hospitals and other healthcare institutions continuously strive toprovide quality patient care. The possibility of medical errors, such aswhere the wrong patient receives the wrong drug at the wrong time, inthe wrong dosage, or even where the wrong surgery is performed, is asignificant concern for all healthcare facilities. Many prescriptiondrugs and injections are identified merely by slips of paper on whichthe patient's name and identification number have been hand-written by anurse or technician who is to administer the treatment. For a variety ofreasons, such as the transfer of patients to different beds and errorsin marking the slips of paper, the possibility arises that a patient maybe given an incorrect treatment. This could be prevented by using anautomated system to verify that the patient is receiving the correctcare. Various solutions to these problems have been proposed, such assystems that use bar codes to identify patients and medications, orsystems allowing the bedside entry of patient data. While these systemshave advanced the art significantly, even more comprehensive systemscould prove to be of greater value.

Delivery, verification, and control of medication in an institutionalsetting have traditionally been areas where errors can occur. In atypical facility, a physician enters an order for a medication for aparticular patient. This order may be handled either as a simpleprescription slip, or it may be entered into an automated system, suchas a physician order entry (“POE”) system. The prescription slip or theelectronic prescription from the POE system is routed to the pharmacy,where the order is filled, so that the medication can be provided to thepatient. Typically, pharmacies check the physician order againstpossible allergies of the patient and for possible drug interactions inthe case where two or more drugs are prescribed, and also check forcontraindications. Depending on the facility, the medication may beidentified and gathered within the pharmacy and placed into a transportcarrier for transport to a nurse station. Once at the nurse station, theprescriptions are again checked against the medications that have beenidentified for delivery to ensure that no errors have occurred.

Typically, medications are delivered to a nurse station in a drug cartor other carrier that allows a certain degree of security to preventtheft or other loss of medications. In one example, the drug cart orcarrier is divided into a series of drawers or containers, eachcontainer holding the prescribed medication for a single patient. Toaccess the medication, the nurse must enter the appropriateidentification to unlock a drawer, door, or container. In othersituations, inventories of commonly-used drugs may be placed in a securecabinet located in an area at or close by a nurse station. Thisinventory may contain not only topical medications but oral, IM-, andIV-delivered medications as well. Nurse identification and a medicationorder number are typically required to gain access to the cabinet.

The nurse station receives a listing of drugs to be delivered topatients at intervals throughout the day. A nurse or other care-giver orother qualified person reads the list of medications to be delivered,and gathers those medications from the inventory at the nurse station.Once all of the medications have been gathered for the patients in theunit for which the nurse station is responsible, one or more nurses thentake the medications to the individual patients and administer thedosages.

Common to all of these systems is the nurse who delivers the medication.The nurse is central to the process of verifying that the rightmedication is given to the right patient in the right dosage at theright time at the point of care. No other person in the facility issituated as well as the nurse delivering the medication to ensure orverify that the appropriate drug is being given to the appropriatepatient.

Such a system though may not be capable of thoroughly verifying that theappropriate medication regimen is being delivered to a patient in thecase where IV drugs are being delivered. For example, a nurse may carryan IV bag to a particular patient area, hang the bag, program aninfusion pump with appropriate treatment parameters, and begin infusionof the medication. The applicable hospital control system, such as thepharmacy information system, may not be informed that the patient hasreceived the medication, and if the information is lost somewhere, thepossibility exists of medicating the patient twice. Thus, there may be abreak in the link of verification that the medication is being properlydelivered to the patient if an event occurs resulting in a deviationfrom the desired treatment parameters.

Moreover, even where the right medication arrives at the right patientfor administration, incorrect administration of the medication may occurwhere the medication is to be administered using an automated orsemi-automated administration device, such as an infusion pump, if theautomated device is programmed with incorrect medication administrationparameters. For example, even where the medication order includes thecorrect infusion parameters, those parameters may be incorrectly enteredinto an infusion pump, causing the infusion pump to administer themedication in a manner that may not result in the prescribed treatment.

One attempt at providing an infusion system with built-in safeguards toprevent the incorrect entry of treatment parameters utilizeshospital-defined drug dosing parameters which are employed by theinfusion instrument's software to monitor the infusion parameter entryprocess and interact with the care-giver should an incorrect entry or anout of range entry be attempted. In such a case, an alert iscommunicated to the care-giver that the parameter entered is eitherincorrect or outside of a range established by the institution wherecare is being provided. The drug dosing parameters consist ofhospital-defined values for infusion parameters or other medicaltreatment guidelines. They may comprise the considered “best practices”of the facility and may be updated from time to time.

Typically, the drug dosing parameters are installed in the device byqualified personnel. However, each type (model) of infusion pump has itsown independent software for creating and installing customized drugparameters for that type and model of pump. Thus, the qualifiedpersonnel must repeat the customization process for each type ofinfusion pump used at the institution. Further, each time theinstitution's guidelines or policies are updated, the drug dosingparameters for each type of infusion pump must be separately updated aswell.

In the case of modular systems having a single programming module thatcontrols multiple infusion pumps or infusion pump modules, such as inALARIS Medical Systems, Inc.'s MEDLEY® Modular Patient Care System, thedrug dosing parameters are installed in the programming module, orcommon Patient Care Unit™ (PCU), and are thereby usable by all theinfusion modules attached to the “system”. However, even with thismodular system, the customizable drug dosing parameters are limited touse with that particular model. Further, they can only be installed inthat model's Patient Care Unit™ (programming module) and not othermodels or devices manufactured by ALARIS and certainly not the devicesof other manufacturers.

While these hospital-defined drug dosing parameters have provided asignificant advance in the art for avoiding medication errors, when morethan one model of patient care device is used by a hospital, the processfor customizing separate databases for each device model requires asignificant amount of time by skilled personnel and introduces a risk ofinconsistency. Therefore, it would be advantageous to provide a moreaccurate and efficient system to create and deploy hospital-defined drugdosing parameters and rules for different models of infusion devices aswell as other patient care devices. It would also be advantageous forhospitals as well as manufacturers to be able to develop and implement asingle customizable set of drug dosing parameters and rules which may beapplied to all the infusion devices and associated monitoring anddiagnostic devices and systems in the hospital.

In some cases, diverse types or models of patient care devices may needto communicate with each other for purposes of sharing information. Forinstance, patient monitoring devices such as vital signs monitors oftenhave the capability of storing transactions from other patient caredevices, such as infusion pumps. These monitoring devices typicallyrequire the parameters of the other patient care devices so thatappropriate correlation, labeling, data validation and storage functionsmay be provided. Additionally, in cases where the drug dosing parametersfurther include rule sets representing patient-condition-specific rulesand/or algorithms that determine dosing parameter(s) as a function ofpatient data obtained from other sources in the network, informationfrom one device may be essential to another device that is utilizing thehospital's drug dosing parameters. Further, some devices may alteroperation in response to the information received from another device,either in accordance with a drug dosing rule or other operationalsoftware in the system or device. For example, the rule for maximum andminimum dose of sodium nitroprusside can be made dependent on thearterial blood pressure measured by a separate instrument. If the meanblood pressure exceeds a predetermined limit or meets a certaincategorization such as “high”, then the dosing parameter defining theupper continuous dose limit would be reduced in accordance with theparameters of the dosing rule for that drug within a selected behaviordescriptor, as that term will be defined below.

However, each healthcare facility typically has a different inventory ofdiverse models of patient care devices, many of which are not compatiblewith each other because they are made by different manufacturers or areotherwise supported by different platforms that use different languagesand/or communication protocols to transmit or receive data. Thus, itwould be advantageous to provide a universal configuration database fromwhich these diverse devices could easily obtain the needed communicationinformation (e.g. data definitions, rules, protocols, structures,definitions) to support communication with other types of patient caredevices. It would also be advantageous if such a system was integratedwith the customizable drug dosing parameters and rules as well as theinfusion/monitoring instrument's operational configuration parameters.

The operational behavior of many infusion devices are capable of beingcustomized through installation of “configurable operation parameters”including such parameters as alarm limits, maximum rates, selection ofoperational modes and languages. Depending on the type of infusiondevice and area in which the device is used, specific settings areneeded to provide optimal care. For instance, the neonatology departmentwill prefer a low rate limit, the smallest air bubble detection limitand special settings for pressure and resistance alarms.

For example, many infusion pumps presently available allow users todetermine the behavior of the medical device by choosing one of a listof behaviors referred to as “profiles”. The parameters of each “profile”are defined generically as behavior descriptors, the elements of whichare selected to provide optimal behavior of the medical device in aspecific care area (ICU, OR, etc) or type of medical care (cardiology,oncology). By the operator's selection of a “profile”, the infusion pumpor other medical device becomes automatically customized to provideoptimal operating features for the patient's in the selected care area.For example, both infusion devices and vital signs monitoring modulesmay be combined in a single integrated patient care system controlled bya central computer referred to as a PCU. The operational behaviors ofmonitoring modules include features such as alarm limits and displayrange. Similar to infusion modules, the behavior of these devices may becustomized through the selection of the desired “profile” or ensemble ofoperating parameters.

A need therefore exists for a hospital-specified configuration databaseto coordinate all the above features, functions, rules and communicationparameters. This “universal” configuration database will integrateindividualized infusion device and monitoring device operationalparameters together with drug infusion parameters and rules. Hence whathas been recognized as a need, and has heretofore been unavailable, isan integrated system for creating and managing customized institutionalguidelines for medical treatments usable with a variety of patient caredevices to provide accurate, efficient, and cost-effective delivery ofhealth care to patients. Such a system should also be capable offacilitating communication between heterogeneous patient care devicesfor further integrating the various aspects of patient care such as theoperational parameters of infusion devices and monitors. The inventionfulfills these needs and others.

SUMMARY OF THE INVENTION

Briefly, and in general terms, the present invention is directed to anew and improved information management system and method capable ofcreating, managing and controlling a hospital-defined universalconfiguration database for patient care devices at a healthcarefacility.

The following definitions of terms are intended to apply in thisdocument: “Universal Configuration Database means a user (orinstitutionally) defined file consisting of electronically stored set ofinformation used to customize the function of a plurality of medicaldevices and/or systems including, but not limited to operatingconfiguration parameters, such as, for example, infusion pump pressurelimits, communication rules and methods such as, for example,communication protocol, baud rate, IP addresses, etc., therapeuticdevice or system rules, including medication delivery rules such as, forexample, infusion dose limits, dose units, maximum and minimum flowrates and the like, and monitoring device or system rules, such as, forexample, alarm limits and parameters such as range, repetition intervaland the like. Elements of the universal configuration database areselectable and installable into various medical devices and systems inorder to provide systematic, uniform operation customized to therequirements of the medical institution and to facilitate exchange ofinformation between diverse sources and repositories of information. Aselection of appropriate “elements” of the universal configurationdatabase is herein called a “dataset.” The term “Ensemble” is defined tomean a subset of the configuration parameters discussed above defining adistinct behavior or the device or system. Selection of a desiredensemble places the parameters associated with that ensemble in the“dataset.” The various operating parameters or rules sets that may beselected to be included in a dataset are also defined herein as“behavior descriptors” because they determine the behavior of themedical device into which they are installed. Thus, the term “dataset”may also be described as a “behavior structure.”

In one aspect, the present invention comprises a plurality of patientcare devices capable of being programmed to operate in accordance with aspecific behavior, each device including a memory for storing at leastone device-specific configuration dataset for controlling the patientcare device in accordance with the specific behavior, a universalconfiguration database containing operating information for a pluralityof device behaviors, a processor operatively connected to the universalconfiguration database and configured to load at least onedevice-specific configuration dataset associated with a selected devicebehavior into the memory of at least one of the patient care devices toprogram the at least one patient care device in accordance with theoperating information contained in the device-specific dataset, and acommunication system operatively connecting each of the plurality ofdevices to the processor.

In another aspect, the patient care system of the present inventionincludes an embodiment wherein each specific behavior corresponds to adifferent infusion pump system, and also wherein the operatinginformation includes medical treatment guidelines and/or deviceoperating characteristics.

In still another aspect, the patient care system of the presentinvention comprises a system wherein the operating information furtherincludes communication protocols and data structures for a plurality oftypes of patient care devices to enable communication between the typesof patient care devices, and/or wherein the processor is configured toload a plurality of device-specific configuration datasets into thememory of one of the patient care devices, and each of thedevice-specific configuration datasets includes a plurality of deviceoperating parameters representing the medical treatment guidelines. In afurther aspect, the system of the present invention may also comprisemeans for activating one of the loaded device-specific configurationdatasets to program the patient care device to operate in accordancewith a desired behavior in response to patient-specific informationcommunicated to the patient care device.

In yet a further aspect, the present invention comprises a patient caresystem including a plurality of patient care devices each having amemory for storing at least one device-specific configuration dataset, aconfiguration database containing operating information includingmedical treatment guidelines and device operating characteristicsassociated with a plurality of a plurality of device behaviors, editingmeans for editing the medical treatment guidelines, wherein the medicaltreatment guidelines that are common to multiple device behaviors areautomatically edited for each of the corresponding device behaviors, andloading means for selectively loading at least one device-specificconfiguration datasets into at least one of the patient care devices inaccordance with a desired device behavior.

In a still further aspect, the present invention comprises a system forcreating device-specific configuration datasets for each of a pluralityof desired device behaviors including a common configuration databasecontaining medical treatment guidelines and device operatingcharacteristics for a plurality of device behaviors, and a processoroperatively connected to the common configuration database andconfigured to construct a device-specific configuration dataset for aselected device behavior from the common configuration database and loadthe device-specific dataset into a memory of at least one patient caredevices to control the patient care device in accordance with theselected device behavior.

In another aspect, the present invention comprises a patient care systemcomprising a plurality of patient care devices having a memory forstoring a configuration dataset and a first processor configured tooperate the patient care device in accordance with the storedconfiguration dataset, a common configuration database in which isstored device communication information comprising communicationprotocols and data structures for a plurality of types of patient caredevices, a second processor operatively connected to the commonconfiguration database and configured to load the database into thememory of a selected patient care device to enable communication betweenthe selected patient care device and other patient care devicesrepresenting different device types than the selected patient caredevice, and a network operatively connecting each of the plurality ofdevices to the second processor.

In still another aspect, the present invention includes a method forcreating device-specific configuration dataset for each of a pluralityof device types comprising the steps of storing operating informationrepresenting a plurality of patient care device behaviors in a commonconfiguration database, wherein the operating information includesmedical treatment guidelines, each guideline including a plurality ofdevice operating parameters for programming a patient care device tohave a selected behavior, editing the device operating parameters forthe medical treatment guidelines, wherein the parameters that are commonto multiple device behaviors are automatically edited for each of thecorresponding device behaviors, constructing at least onedevice-specific configuration dataset from the common configurationdatabase, the device-specific configuration database including only themedical information from the common configuration database associatedwith a selected device behavior, and loading the at least onedevice-specific configuration dataset into a memory of a patient caredevice.

In a further aspect, the present invention comprises a system forrecognizing medical treatment devices and for loading device specificinformation into a recognized medical treatment device to configure thedevice comprising a communication module for establishing communicationwith a medical treatment device, a recognition module configured toquery the medical treatment device and determine an identification ofthe medical treatment device, and a loading module configured tocommunicate with the medical treatment device, to construct a datasetfrom a plurality of stored datasets in accordance with theidentification of the medical treatment device and to communicate theconstructed dataset to the medical treatment device and load the datasetinto the medical treatment device to configure the medical treatmentdevice.

Other features and advantages of the invention will become apparent fromthe following detailed description, taken in conjunction with theaccompanying drawings, which illustrate, by way of example, the featuresof the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram of a hospital-wide information and caremanagement system incorporating principles of the present invention;

FIG. 2 is a schematic diagram of an interface unit and the contents ofits memory, including a diagram of a universal configuration database,according to aspects of the present invention;

FIG. 3 is a schematic diagram illustrating more detailed aspects of auniversal configuration database according aspects of to the presentinvention;

FIG. 4 is a schematic representation of various elements of oneembodiment of the universal configuration database of FIG. 2;

FIG. 5 is a block diagram illustrating a number of different infusiontypes supported by the interface unit of the present invention;

FIG. 6 is a schematic diagram illustrating another embodiment of asystem for managing a universal configuration database including acommon drug dosing rules library for patient care devices in accordancewith aspects of the present invention;

FIG. 7 is a schematic diagram of an alternative embodiment of thepatient care management system of the present invention; and

FIG. 8 illustrates the process steps used to relate a programming modulewith a patient, in accordance with one embodiment of the presentinvention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention provides a system and method for creating,managing and installing a universal configuration database or portionsthereof and using this database to customize the behavior of patientcare devices and systems in a healthcare facility according to thespecifications of that facility. Additionally, the universalconfiguration database provides rules and parameters to facilitatecommunication between diverse patient care devices from multiplemanufacturers.

Digital Communication Network

Referring now to drawings in which like reference numerals are used torefer to like or corresponding elements among the figures, there isgenerally shown in FIG. 1 an integrated hospital-wide information andcare management system 28 in accordance with aspects of the presentinvention. Various subsystems of the facility's information and caremanagement system are connected together by way of a communicationsystem 30. The communication system 30 may be, for example, a local areanetwork (LAN), a wide area network (W AN) , Inter-or intranet based, orsome other communication network designed to carry signals allowingcommunications between the various information systems in the facility.For example, as shown in FIG. 1, the communication system 30 connects,through various interfaces 32, a hospital administration system 34, apharmacy information system 36, a physician order entry (POE) system 38,a control system 40, and a configuration management system 42. Aplurality of patient care devices or systems 44, 46 and 48 may also beconnected to communication system 30.

The communication system 30 may comprise, for example, an Ethernet (IEEE522.3), a token ring network, or other suitable network topology,utilizing either wire or optical telecommunication cabling. In analternative embodiment, the communication system 30 may comprise awireless system, utilizing transmitters and receivers positionedthroughout the care-giving facility and/or attached to varioussubsystems, computers, patient care devices and other equipment used inthe facility. In such a wireless system, the signals transmitted andreceived by the system could be radio frequency (RF), infrared (IR), orother means capable of carrying information in a wireless manner betweendevices having appropriate transmitters or receivers. It will beimmediately understood by those skilled in the art that such a systemmay be identical to the system set forth in FIG. 1, with the exceptionthat no wires are required to connect the various aspects of the system.

Each of the various systems 34,36,38,40 and 42 generally comprise acombination of hardware such as digital computers which may include oneor more central processing units, high speed instruction and datastorage, on-line mass storage of operating software and short termstorage of data, off-line long-term storage of data, such as removabledisk drive platters, CD ROMs, or magnetic tape, and a variety ofcommunication ports for connecting to modems, local or wide areanetworks, such as the network 30, and printers for generating reports.Such systems may also include remote terminals including video displaysand keyboards, touch screens, printers and interfaces to a variety ofclinical devices. The processors or CPUs of the various systems aretypically controlled by a computer program or programs for carrying outvarious aspects of the present invention, as will be discussed morefully below, and basic operational software, such as a Windows™operating system, such as Windows NT™, or Windows 2000™, or Windows XP™,distributed by Microsoft, Inc., or another operating programdistributed, for example, by Linux, Red Hat, or any other suitableoperating system. The operational software will also include variousauxiliary programs enabling communications with other hardware ornetworks, data input and output and report generation and printing,among other functions.

Modular Patient Care Device

Patient care devices and systems 44, 46 and 48 may comprise a variety ofdiverse medical devices including therapeutic instruments such asparenteral and enteral infusion pumps and respirators, physiologicalmonitors such as heart rate, blood pressure, ECG, EEG, and pulseoximeters, and clinical laboratory biochemistry instruments such asblood, urine and tissue sample measurement instruments and systems.

In one embodiment, the patient care device 48 comprises a modular systemsimilar to that described in U.S. Pat. No. 5,713,856 to Eggers et al.,which is incorporated herein by reference. In this embodiment, thepatient care device 48 comprises an advanced programming module 50, alsoreferred to as interface unit 50, connected to one or more functionalmodules 52, 54, 56, 58. Interface unit 50 includes a central processingunit (CPU) 60 connected to a memory, e.g. random access memory (RAM) 62,and one or more interface devices such as user interface device 64, adata input device 66, a network connection 68, and an auxiliaryinterface 70 for communicating with additional modules or devices.Interface unit 50 also preferably, although not necessarily, includes amain non-volatile storage unit 72, preferably a hard disk drive, forstoring software and data and one or more internal buses 74 forinterconnecting the aforementioned elements. As shown in FIG. 1, patientcare devices 44, 46 may represent single-module patient care devicesthat include the same components as the interface unit 50.

In a typical embodiment, user interface device 64 is a touch screen fordisplaying information to a user and allowing a user to inputinformation by touching defined areas of the screen. Alternatively, userinterface device 64 could include any means for displaying and inputtinginformation, such as a monitor, a printer, a keyboard, softkeys, amouse, a track ball and/or a light pen. Data input device 66 ispreferably a bar code reader capable of scanning and interpreting dataprinted in bar coded format. Alternatively, data input device 66 couldbe any device for entering data into a computer, such as devices forreading magnetic strips, PCMCIA smart cards, radio frequency cards, RFIDtags, memory sticks, CDs, DVDs, or any other analog or digital storagemedia. Other examples of data input device 66 include a voice activationor recognition device or a portable personal data assistant (PDA).Depending upon the types of interface devices used, user interfacedevice 64 and data input device 66 may be the same device.Alternatively, although data input device 66 is shown in FIG. 1 to bedisposed within interface unit 50, one skilled in the art will recognizethat data input device 66 may be integral within pharmacy informationsystem 36 or located externally and communicating with pharmacyinformation system 36 through an RS-232 serial interface or any otherappropriate communication means. Auxiliary interface 70 is preferably anRS-232 communications interface, however any other means forcommunicating with a peripheral device such as a printer, patientmonitor, infusion pump or other patient care device may be used withoutdeparting from the scope of the invention.

Digital Communication Methods

Network connection 68 is preferably a direct network connection such asa T1 connection, an integrated services digital network (ISDN)connection, a digital subscriber line (DSL) modem or a cable modem.Alternatively, any direct or indirect network connection may be used,including, but not limited to a telephone modem, an Mm system, an RS232interface, an auxiliary interface, an optical link, an infrared link, aradio frequency link, a microwave link or a WLANS connection.

Modular Patient Care Devices

Functional modules 52, 54, 56, 58 are any patient care devices under theimmediate control of the interface unit 50, for providing care to apatient or for monitoring patient condition. In one embodiment of thepresent invention, at least one of functional units 52, 54, 56,58 is aninfusion pump module such as an intravenous infusion pump for deliveringmedication or other fluid to a patient. For the purposes of thisdiscussion, functional unit 52 is an infusion pump module. Each offunctional units 54, 56, 58 may be any therapeutic or monitoring deviceincluding, but not limited to, an infusion pump module, a syringeinfusion module, a Patient Controlled Analgesia (PCA) module, anepidural infusion module, an infusion module pump, a blood pressuremonitor, a pulse oximeter, an EKG monitor, an EEG monitor, an end-tidalCO₂ (etCO₂), a heart rate monitor or an intracranial pressure (ICP)monitor. Alternatively, functional module 54, 56 and/or 58 may be aprinter, scanner or any other peripheral input/output or communicationdevice.

Each functional unit 52, 54, 56, 58 communicates directly or indirectlywith interface unit 50, which provides overall control and display ofthe status of modular patient care device 48. In one embodiment,functional units 52, 54, 56, 58 are connected physically andelectronically in serial fashion to one or both ends of interface unit50 as shown in FIG. 1 and as detailed in Eggers et al. However, oneskilled in the art will recognize that there are other means forconnecting functional modules with the interface unit which may beutilized without departing from the scope of the invention. It will alsobe appreciated that devices such as pumps or monitors that providesufficient programmability and connectivity may communicate directlywith the network without a separate interface unit. As described above,additional medical devices or peripheral devices may be connected topatient care system 48 through one or more auxiliary interfaces 70.

Each functional unit 52, 54, 56, 58 typically includes module-specificcomponents 76, a microprocessor 78, a volatile memory 80 and anonvolatile memory 82 for storing information. It should be noted thatwhile four functional modules are shown in FIG. 1, any number of devicesmay be connected directly or indirectly to central computer 50. Thenumber and type of functional modules described herein are intended tobe illustrative, and in no way limit the scope of the present invention.Module-specific components 76 include any components necessary foroperation of a particular module, such as, for example, a pumpingmechanism for infusion pump module 52.

While each functional unit is typically capable of a least some level ofindependent operation, interface unit 50 monitors and controls overalloperation of modular patient care device 48. For example, as will bedescribed in more detail below, interface unit 50 provides programminginstructions and power to the functional unit 52, 54, 56, 58 andmonitors the status of each module receiving data for both display,coordination of control of other modules and for communication toconnected medical devices and information systems.

Universal Configuration Database

According to one embodiment of the present invention, patient caredevices and systems 44, 46, 48 are capable of being customized throughinstallation of data, rules and operating parameters derived from auniversal configuration database containing institutionally-establishedguidelines for medical treatments, such as a drug dosing parameters andrules, device operating characteristics and communication parameters.Each of the patient care devices or system 44, 46, 48 may comprise adifferent device type having at least some of its own distinct deviceoperating characteristics or features.

The following definitions of terms are intended to apply in thisdocument: “Universal Configuration Database means a user (orinstitutionally) defined file consisting of electronically stored set ofinformation used to customize the function of a plurality of medicaldevices and/or systems including, but not limited to operatingconfiguration parameters, such as, for example, infusion pump pressurelimits, communication rules and methods such as, for example,communication protocol, baud rate, IP addresses, etc., therapeuticdevice or system rules, including medication delivery rules such as, forexample, infusion dose limits, dose units, maximum and minimum flowrates and the like, and monitoring device or system rules, such as, forexample, alarm limits and parameters such as range, repetition intervaland the like. Elements of the universal configuration database areselectable and installable into various medical devices and systems inorder to provide systematic, uniform operation customized to therequirements of the medical institution and to facilitate exchange ofinformation between diverse sources and repositories of information. Aselection of appropriate “elements” of the universal configurationdatabase is herein called a “dataset.” The term “Ensemble” is defined tomean a subset of the configuration parameters discussed above defining adistinct behavior or the device or system. Selection of a desiredensemble places the parameters associated with that ensemble in the“dataset.” The various operating parameters or rules sets that may beselected to be included in a dataset are also defined herein as“behavior descriptors” because they determine the behavior of themedical device into which they are installed. Thus, the term “dataset”may also be described as a “behavior structure.”

A device type, for example, may represent a distinct brand, model,platform or manufacturer of a patient care device. Two differentinfusion pump systems which perform the same or similar functions mayrepresent different device types where they are physically andfunctionally separate and distinct systems or platforms, either from thesame or different manufacturer. Different device types may also beincompatible with each other in terms of communicating with each otherfor purposes of sharing data within a health care facility.

The BEHAVIOR DESCRIPTOR elements of the device specific datasetinstalled in a patient care device, either in a memory of the device orin some other storage media accessible by the device or a processorcontrolling the device, will only be those specific for that type ofdevice. Other information installed in the device or system may includeinfusion dosing parameters and rules, dose sequencing, and communicationparameters.

The device-specific datasets are created by the configuration managementsystem 42 which, as shown in FIG. 1, includes a universal configurationdatabase 84 containing configuration data and parameters for a pluralityof diverse device and system types. For example, the universalconfiguration database may contain medication delivery parameters suchas drug infusion parameters and rules and device operatingcharacteristics for a plurality of diverse device types. An editing tool86 permits qualified personnel such as a biotechnical engineer at theinstitution, to customize the universal configuration database toinclude the institution's accepted values for the various parameters inthe guidelines.

An installation tool 88 facilitates transfer of appropriate portions ofthe universal configuration database into each device or systemaccording to its type. In this way, device or system-specific datasetsare created and loaded into the appropriate patient care devices orsystems. Both the universal configuration database editing tool 86 andthe installation tool 88 may be embodied in software applicationsexecuting on a CPU 90 associated with the configuration managementsystem 42.

The user may interact with the system for editing database elements orfor creating media for use in carrying out the installation of aconfiguration. This may be performed using interface device 92, whichmay be a printer, floppy disc drive, CD writer, bar code writer, EPROMwriting device or any other media appropriate for transfer of aconfiguration. In the case that the hospital has available a digitalcommunication network with which medical devices (also referred to asclinical devices) and systems are in communication, the configurationmanagement system 42 may include a network connection 94 for installingthe device-specific configuration into the patient care devices via thecommunication system 30.

In one embodiment of the present invention, one or more of the patientcare devices or systems 44, 46, 48 is capable of operating in one ofseveral selectable modes with each mode defined by the universalconfiguration database. Thus, the universal configuration database 84may contain multiple elements for a plurality of patient care devicesand facilitate installation of the selected mode in accordance with thedevice type. These particular elements define a behavior of the pumpthat may be changed as necessary depending on the environment in whichthe device is being used, patient specific information, medications orother therapeutic agents to be delivered, or vital signs or laboratoryresults being monitored. A particular behavior stored in a patient caredevice is selected based, at least in part, by patient-specificinformation such as patient location, age, physical characteristics, ormedical characteristics. Medical characteristics include, but are notlimited to, patient diagnosis, treatment prescription, medical history,medical records, patient care provider identification, physiologicalcharacteristics or psychological characteristics. As used herein,patient-specific information may also include care provider information(e.g., physician identification) or a patient care device's location inthe hospital or hospital computer network. Patient care information maybe entered through interface device 64, 66, 68 or 70, and may originatefrom anywhere in network 30, such as, for example, from the hospitaladministration system 34, pharmacy information system 36, physicianorder entry system, or any other system or department in the facility.

Data to and from the various data sources can be converted intonetwork-compatible data with existing technology, and movement of theinformation between the medical device and network can be accomplishedby a variety of means. For example, patient care devices or systems 44,46, 48 and the network may communicate via automated interaction and/ormanual interaction. Automated interaction may be continuous orintermittent and may occur through direct network connection 68 (asshown in FIG. 1), or alternatively through RS232 links, MIB systems, RFlinks such as BLUETOOTH (Arntel Corp., San Jose, Calif.), IR links,WLANS, digital cable systems, telephone modems or other communicationmeans. Manual interaction between patient care devices or systems 44,46, 48 and the network involves physically transferring, intermittentlyor periodically, data between systems using, for example, user interfacedevice 64, data input device 66, bar codes, computer disks, portabledata assistants, memory cards, or any other media for storing data.Preferably, the communication means is bidirectional with access to datafrom as many points of the distributed data sources as possible.Decision-making can occur at a variety of places within the network. Forexample, and not by way of limitation, decisions can be made in hospitaladministration system 34, pharmacy information system 36, otherdepartments or systems such as a nursing station or a bedside CPU, orwithin patient care device or system 44, 46 or 48 itself.

Referring to FIG. 2, in one embodiment of the present invention, theuniversal configuration database 84 includes one or more componentscontaining available treatment protocols, drug library information, rulesets, device operating characteristics such as device or moduleoperating limits and device features, and possibly other information fordefining particular operating parameters for a plurality of types ofpatient care devices. At least a portion of the database containsinformation that is specific for each type of device. As shown in FIG.2, Device Type module 100 in the database 84 contains device-specificinformation for Device Types A, B and C identified by reference numerals102, 104 and 106, respectively. While three devices types are depictedin FIG. 2, more or fewer types of devices may be supported by thedatabase. The fields for each Device Type 102, 104, 106 contain theinformation specific for each device type, such as device operatingcharacteristics, as will be described in more detail below.

Installation of a Dataset

The universal configuration database 84 may also include componentsdefining a plurality of datasets 200, 202, 204 and 206 that definedesired medical device or system behaviors that may be customized foreach device type using the editing tool 86. Customized, device-specificconfiguration datasets may then be installed into patient care devices,such as interface unit 50, as shown in FIG. 3. Although this embodimentis primarily described with respect to the interface unit 50 of patientcare device or system 48, it will be understood that appropriateconfiguration datasets may similarly be loaded into the other patientcare devices 44, 46. The configuration dataset is preferably stored inmemory 72 of interface unit 50, however appropriate elements of aspecific device configuration dataset may be stored within a functionalunit 52, 54, 56, 58 (FIG. 1). One skilled in the art will understandthat, while memory 72 is preferably an internal hard disk, any permanentor removable storage media including, but not limited to, CD-ROM,EEPROM, diskette, tape, external hard disk, memory card, flash memory,etc. may be used. Optionally, portions of configuration datasets 200,202, 204, 206 may be stored in volatile memory such as RAM 62.

Each of the configuration datasets 200, 202, 204, 206 preferablyincludes one or more unique behavior type identifiers, or pointers, 210,212, 214, 216, for identifying the respective behavior that will beimparted to the functional unit when the configuration dataset isinstalled in the functional unit. Each configuration dataset 200, 202,204, 206, which may also be considered to be behavior structures fordetermining and controlling the behavior of the medical devices orsystems into which they are installed, includes a plurality of fieldswhich define, for example, available infusion parameters and rules,device operating characteristics such as device or module operatinglimits and device features, and possibly other information for definingparticular operating parameters for a plurality of types of patient caredevices. As mentioned previously, the device-specific information may beorganized in the Device Type module 100.

The individual behavior structures of a configuration dataset 200, 202,204 and 206 typically consist of a set of operating parameters and drugdosing rules and may be treatment location specific (e.g. intensive careunit ICU, neonatal intensive care unit NICU, pediatrics, oncology,etc.), disease state specific (intracranial pressure management, bonemarrow transplant, etc.), user specific (LPN, RN, physician, etc.), orcreated by any other rationale. For example, according to one embodimentof the present invention, when patient care device or system 48 islocated in the ICU it utilizes behavior 200, and when device 48 islocated in the NICU it utilizes behavior 202. Each behavior 200 and 202,respectively, contains particular operating parameters, treatmentprotocols, features, etc. that configure device or system 48 for usewith patients in that unit of the hospital.

It should be noted that while FIG. 2 shows that each dataset includesthe same categories and types of information, the structure of thedataset may vary considerably in terms of the types and amounts ofinformation it contains. For devices/systems capable of multipleuser-selectable behaviors, elements of the configuration dataset, whenselected, at least in part define the operational behavior of the deviceor system 48 and includes a plurality of distinct behavior datastructures.

FIG. 3 is a more detailed representation of a sample Infusate Deliverydata structure 204 according to one embodiment of the present invention.Configuration database 204 includes an ensemble structure 230 comprisinga plurality of ensembles 232, 234, 236, 238, 240. Each ensemble includesa plurality of fields of default operating parameters. In some cases aninfusion ensemble may include a complete detailed infusion instructionwith all of the default parameter values defined. Other infusionensembles may have partially defined parameters with additional dataentry required by the user at the point of care. For example, ensemble A232 of FIG. 3 includes fields of default operating parameter values andother data for controlling a medication infusion pump. The fields ofthis example include drug name 300, concentration 304, container size(s)308, default dose rate 312, default bolus 316, maximum dose rate 320,minimum dose rate 324, maximum cumulative dose 328, drug incompatibility332 and an ID field, record pointer 336, for identifying or “calling”the specific ensemble record. Each field typically includes storeddefault parameter values that collectively define a specific infusionensemble. Some fields, such as drug incompatibility 332, may alsoinclude a reference or link to a drug information library typicallyresident within the hospital's pharmacy computer system containingrelevant information. Such references to commonly used data librariesallow data to be shared between ensembles and/or the universalconfiguration database to avoid duplicate storage and entry and to allowefficient updating of database information.

Alternatively, all ensembles need not be stored within eachconfiguration dataset. Rather, ensembles from different configurationdatasets may be saved in a master database or library, with eachindividual configuration datasets containing reference links toparticular ensembles stored in the universal configuration database.Such an arrangement is advantageous because it avoids duplicate storageof identical ensembles and facilitates updating of information containedwithin the universal configuration database.

Following selection of a particular infusion ensemble, certaininformation potentially resident in other locations may be accessed. Forexample, device or system 48 may query a hospital communication networkusing the communication parameters defined (if present) to automaticallyobtain data such as patient weight from the patient's electronic recordsin hospital administration system 34, dose ordered from the computerizedphysician order entry system (CPOE), drug incompatibility data from apharmacy information system 36 and clinical chemistry results which arepertinent to the infusion and referenced by the infusion ensemble rules.Additional verification of the dose and medication identity may beaccomplished through access to the Medication Administration Record (MARor eMAR) contained in the pharmacy information system 36. In the absenceof a digital communication network, the user may manually enter datasuch as the patient weight and total dosage directly into the device orsystem. In one embodiment of the invention, information associated witha drug specific ensemble is automatically entered into the device orsystem by selection of a specific infusion ensemble. The suppliedinformation may include, for example, the dose and flow rate limits andmode (hard limits or soft limits, or both), dose units, drug amount anddiluent limits, and bolus limit. Information required to complete thedose program that was not available from the infusion ensemble data,such as patient weight, drug amount, diluent volume, dose rate and totaldosage, may be manually entered through a user interface. The userinterface may confirm the automatically selected parameters as prompted.

Different configuration datasets, or behavior structures, typicallyinclude different fields and/or different parameter values, within eachfield. Thus, Ensemble B 234 might include additional fields compared toEnsemble A 232, where the additional fields define instructions and/orparameters for implementing one or more different infusion types such asprimary/secondary infusion, multichannel coordinated infusion andmultidose ensembles. Alternatively, Ensemble B 234 could include thesame fields as Ensemble A 232, and differ only in terms of one or moreparameter values in one of the fields. For example, both ensembles couldbe designed to provide infusion of the drug dopamine, where one ensemblehas a concentration 304 value of 400 mg/250 mL while the other has aconcentration 304 value of 800 mg/250 mL.

Referring again to FIG. 4, the Rule Sets module 250 of configurationdatabase 204 includes rules and/or algorithms that may be used to helpdefine particular parameters within a configuration database. Forexample, Rule Sets module 250 could include an algorithm that modifiesthe maximum allowable infusion rate or some other parameter based upondata obtained from other sources in network 30, such as patient age,body weight or medical history from hospital administration system 34 ortest results from the laboratory. Other rule sets in the Rule Setsmodule 250 may provide warnings or recommendations upon the occurrenceof particular events within pump module 52, such as occlusion of theinfusion line.

Still other rule sets within module 250 may contain algorithms thatutilize measurements from one or more functional modules to modifyoperation of another functional module. For example, module 250 maycontain a rule set that monitors blood pressure and intracranialpressure in a head trauma patient and calculates resulting perfusionpressure. The system then notifies the user when perfusion pressurefalls outside of a defined range and recommends adjusting infusion rateof a therapeutic agent to increase blood pressure or to decreaseintracranial pressure.

Together, the ensembles and rule sets generally define the acceptedguidelines for appropriate medical treatment parameters established byan institution. They may include, for example, the institutionallyestablished guidelines or limits on drug administration parameters, suchas dosage, frequency of administration, and other delivery relatedinformation such as, for example, appropriate flow rates and infusiondurations for programming infusion pumps. Additionally, in conjunctionwith the plurality of configuration databases, the protocols and rulesets may encompass guidelines for providing drug administrationappropriate to particular patient treatment areas having different setsof delivery parameters for similar medications, such as medicationadministration directed to geriatric, pediatric and oncology patients.Guidelines may also be included that are directed to particular therapyregimens, such as chemotherapy regimens or regimens for treating chronicinfection or pain. In one embodiment of the present invention, theensembles and rule sets may include “hard” and “soft” limit values onphysiological parameters (such as CO₂, SpO₂, respiration rate, andothers), PCA dosing parameters, and other infusion and vital signparameters.

As discussed previously, the Device Type module 100 containsdevice-specific information for a plurality of patient care devicesintegrated into the configuration database 84 (FIG. 1). Thedevice-specific information contained in each field of Device Types A, Band C, identified by reference numerals 102, 104, 106 respectively,generally includes device operating characteristics, such as device andfunctional module operating limits and/or various device features. Asshown in FIG. 4, pump operating limits and available infusion featuresmay be included where the patient care device is a type of infusionpump. Each Device Type 102, 104, 106 may also include a pointer 252 foridentifying the records for that specific device.

Additional portions of the configuration database, such as the ensemblesor rule sets described above, may also contain device-specificinformation and may be organized according to device type. In suchcases, some or all of the ensembles may be contained within the DeviceType module 100 or at least associated with the correct device typepointer 252 for identifying the relevant device types for that ensemble.In FIG. 3, the appropriate device-specific information from Device Typemodule 100 is shown loaded into the patient care device or system 48 andcomprises pump limits and infusion features as discussed in more detailbelow.

As shown in FIGS. 2 and 3, the Pump Limits module 260 of configurationdatabase 204 contains information that defines the overall operatinglimits of infusion pump module 52 and other pump devices, if any,attached to interface unit 50. The Pump Limits module 260 typicallyincludes at least three fields, Air In Line (AIL) Limits 262, Max Rate264, and Max Pressure 268. Because the Pump Limits module 260 of eachconfiguration database 200, 202, 204, 206 potentially contains differentparameters and values, module 260 helps define the operatingcharacteristics or mode in which device 50 operates when a particularconfiguration database 200, 202, 204, 206 is active.

Air in Line (AIL) Limits 262 defines an allowable size of asingle-bubble which may be passed through an infusion line connected toa patient and/or for the maximum percentage of air bubbles present whichfall below the single-bubble threshold. Allowable AIL Limits may differfor particular patients or particular locations in the hospital. Forexample, an allowable limit of 50 μL may be set for pediatric patients,while a limit of 100-200 μL is used for general adult patients and 500μL for operating room and/or trauma patients.

Max Rate 264 defines the maximum allowable infusion rate for an infusionpump operating under that particular configuration database 20. Again,the defined Max Rate 264 values may differ among patient class,attributes, location, and the like. For example, the maximum rate fordelivering heparin to pediatric patients may be set at 10 units/Kg/hr,while adult patients have a limit of 500-1 000 units/hr.

Feature Enable/Disable module 270 of configuration database 204 defineswhich particular features, such as infusion types for pumps, areavailable to the user of system 50 when configuration database 204 isactivated for a particular device type. In a preferred embodiment of thepresent invention, patient care system 50 is capable of supporting awide variety of such features, ranging from simple primary infusionsused for hydration and keep-vein-open (KVO) applications to complexmultichannel delivery applications. In one embodiment, the FeatureEnable/Disable module 270 provides the device feature information forthe various patient care device(s). In the embodiment in which there aremultiple configuration databases, the Feature Enable/Disable module 270further designates for each configuration database which of thesefeatures are enabled and disabled for that configuration.

FIG. 5 illustrates some of the various features or infusion types thatare supported by patient care system 50 according to one embodiment ofthe present invention. These features include, but are not limited to,Drug Calc 502, Primary/Secondary 504, Delayed Start (Del Start) 506,Multi Dose 508, Total Parenteral Nutrition (TPN) 510, Multi Step 512,and Multi-Channel Coordinated Infusion (MCCI) 514. As mentionedpreviously, each of these features or infusion types may be implementedby a particular ensemble of behavior characteristics that are defined bythe information stored in the various fields and modules of aconfiguration dataset or behavior structure. The foregoing features aredescribed briefly below; see U.S. Pat. No. 5,713,856, incorporatedherein in its entirety, for a more detailed description of each.

Drug Calc 502 is a feature that allows calculation of drug infusionparameters such as rate or dose, based on patient weight, time units,and drug concentration. For example, the drug calculation function ofthe system allows the user to either: enter the desired drug dose andthe infusion pump functional unit microprocessor calculates the correctflow rate to achieve the desired dose; enter the desired flow rate andthe pump functional unit calculates the corresponding drug dose; orenter the desired bolus dose and the duration and the pump functionalunit calculates the bolus rate and the VTBI. The system may additionallyinclude a pediatric drug calculation function 524 which allows the userto enter, for example, flow rate, dose, and diluent volume. From theseuser entered parameters, the system calculates the amount of drug toadmix with the diluent to achieve a drug concentration consistent withthe selected dose and flow rate. Additional details regarding Drug Calc502 features are found in U.S. Pat. No. 5,713,856.

Typically, Drug Calc 502 mode is used to ensure accuracy of infusionrate data where a user enters at least a portion of the infusion programdata manually, e.g. through a touch screen or a keypad. For example,Drug Calc 502 may be used in conjunction with a drug-specific protocolsuch as stored in a configuration database. Alternatively, Drug Calc 502feature may be used in combination with a stored ensemble that isidentified by a coded label to calculate missing parameter values or torecalculate new values (for example, when a prescription includes adeviation from the standard protocol values).

Pri/Sec 504 feature allows use of ensembles utilizing a primary infusionin conjunction with a secondary infusion solution. Historically aprimary infusion with an antibiotic secondary would be programmed byentering the primary and secondary rate and VTBI. In the presentinvention, a user can simply select the appropriate antibiotic regimenfrom the list infusion protocols and have the appropriate parametersautomatically retrieved. The user may then simply confirm the parametersand start the infusion.

Delay Start 506 delays the start of an infusion protocol or othertreatment for a particular duration of time or until a particular timeof day. Alternatively, start may be delayed until the happening of aparticular event. Such events include, but are not limited to, a signalfrom the interface unit in response to measured vital signs or otherphysiological parameters, completion of a stage of treatment by anothermodule, or a signal or data received by system 50 over communicationsystem 30.

Multi Dose 508 allows multiple doses of a drug to be delivered overtime. An ensemble incorporating the Multi Dose 508 feature typicallyincludes parameters for infusion rate, volume/dose, dose interval,number of doses and start time. As with all other ensembles stored in aconfiguration database, a stored Multi Dose 508 ensemble may be selectedor activated from the configuration database simply by scanning a codeddrug label containing the ensemble identifier (with or withoutinstructions for deviating from default ensemble values). Any missing ordifferent values may then be entered by the user.

TPN 510 provides for total parenteral nutrition delivery using standardor custom ramp and taper protocols known to those skilled in the art.For example, a typical TPN delivery protocol defined by a suitableensemble of behavior characteristics defined by a configuration datasetfor delivering 2500 calories over an eight hour period utilizes aninitial slow rate of delivery with a gradual increase to a maintenancerate for a period of six to seven hours, then a gradual decrease tocomplete the infusion.

Multi Step 512 is similar to TPN 510 in that it allows delivery of asubstance at various rates/volumes during a drug delivery oradministration. Standard 530 defines standard multi• step drug deliveryschedules that are commonly used without deviation for differentpatients. Custom 532 defines multi-step drug delivery schedules that arecustomized for particular situations. For example, a custom multi-stepdrug delivery schedule may be used for delivery of dobutamine toincrease heart rate during a stress test. Such a protocol typicallyvaries the delivery schedule of the drug to a patient over time, andpatient weight or age is used as a factor to select a particular drugdelivery schedule. Any number of custom multi-step delivery schedulesmay be defined and used by one skilled in the art.

MCCI 514 may be used in conjunction with Multi Dose 508 and/or DelayStart 506 features to program complex coordinated infusion involvingdifferent solutions being infused from multiple modules, or channels.

One skilled in the art will appreciate that the features and infusiontypes shown in FIG. 5 are intended to be illustrative of the presentinvention, and that patient care device 48 may support additional ordifferent features than those described herein. Furthermore, the fieldsfor other device types in the Device Type module 100 (FIG. 4) mayinclude different categories and types of information than thatdescribed herein with respect to patient care device or system 48. Incases where there are multiple configuration databases supported for aparticular device type,

the device operating characteristics or other device-specificinformation for the device type may be the same or different among thevarious configurations.

Referring again to FIGS. 2-3, the Device Communications module 400includes information to support communications between different typesof patient care devices 402, 404, 406. The Device Communication module400 may include fields for a Communication Protocol 408 and a DataStructure 410 for each type of patient care device 402, 404, 406 forwhich communication is to be supported. The Communication Protocol 408and Data Structure 410 fields contain the information needed toestablish communication with a particular type of patient care device.Any other fields necessary to define the “language” for a type of devicemay also be integrated in the Device Communications module 400.

With the Device Communication module 400 loaded into a device as shownin FIG. 2, the device has the means to make requests of another deviceaccessible via a wired or wireless network, or other suitablecommunication means. For example, a device may send a query to adifferent device over the network, by providing an address and patientidentification along with the desired query, and receive informationfrom the queried device in response. Thus, different types of patientcare devices such as infusion pumps, vital signs monitoring devices andphysiological sensors that are not typically compatible with each othercan now readily share information. The Device Communication Module isespecially useful in conjunction with the Rule Sets module which oftenprovides rules relating parameters of different patient care devices toeach other.

Another aspect of an embodiment of the present invention is illustratedin FIG. 4. In this embodiment, an exemplary universal configurationdatabase 420 consists of information that is structured to allowcreation and modification of datasets 437 which are then used toconfigure and program various medical devices and systems with clinicaland operating parameters so as to impart desired behaviors to themedical devices and systems.

As shown in FIG. 4, universal configuration database 420 includes commoninfusion parameters 425, such as, for example, a list of drugs, defaultsettings and drug dosing rules, and parameters defining one or moreclinical or operating behaviors 430. Universal configuration database420 also includes device or system specific information, which may beorganized as datasets 437. For example, the illustrated universalconfiguration database 420 includes datasets 437 for medical devices andsystems 435, which are, for example, a Signature Edition® Gold pump, aMedley® L VP pump, a Medley® SP pump, a Medley® ETC02 (end tidal CO2)monitor, a blood pressure monitor and a pharmacy system. The SignatureEdition Gold and Medley pumps, and the Medley ETC02 monitor are productsof ALARIS Medical Systems, Inc.

The datasets 437 of each of the above identified medical devices andsystems include various clinical and operating parameters and rule setsthat, in additional to any device specific characteristics, define oneor more behavior descriptors 440 that program the medical device orsystem to act in a desired way. In other words, the medical devices andsystems are programmed to behave in a way that is selected by thepersonnel of the institution.

Datasets 437 may also include appropriate communication parameters 445to allow communication of the medical devices and systems with otherdevices, systems, and/or other institutional systems, as illustrated inFIG. 1, using appropriate communication means 465. The datasets 437 aretypically installed using a software too 1450 into the appropriatemedical device or system. The software installation tool imparts thedesired behavior into the medical device or system by installingclinical parameters for various behaviors 455, operating characteristicsfor various behaviors 460 and suitable communication parameters 445 intomedical devices and systems 435. The operation of such softwareinstallation tools is well known in the art and will not be described indetail herein.

Referring now to FIG. 6, an embodiment of the present invention is shownin which the universal configuration database 84 includes a masterconfiguration database 540 that stores the various ensembles 542, rulesets 544, device operating characteristics 546 and device communicationinformation 548 for each of the different device types. The ensembles542, rule sets 544, device operating characteristics 546 and devicecommunication information 548 may be stored as separate configurationdatabases, or otherwise organized into data sets, within the masterconfiguration database 540. Each individual protocol, rule set, deviceoperating characteristic and device communication information may beidentified by a unique pointer for identifying and calling that datafrom the universal configuration database. The universal configurationdatabase 84 further includes a separate Device Type Module 550 havingfields for device types A, Band e, identified by reference numerals 552,554 and 556, respectively, which contain reference links to the data inthe master configuration database relevant to each particular devicetype. Thus, the data in the universal configuration database may beshared by the various device types and the editing module 86 (FIG. 1)may be used to enter and/or update data in the master configurationdatabase 540 efficiently without duplicating entry of information usedby multiple device types. In cases where the universal configurationdatabase 84 also supports multiple configuration datasets, a deviceconfiguration module containing reference links to the masterconfiguration database 540 may be used in conjunction with Device Typemodule 550 to further provide different configuration databases to thepatient care devices.

Loading tool 88 (FIG. 2) selects a designated device type in the DeviceType module 550, obtains the appropriate data from the masterconfiguration database in accordance with the reference links, andbuilds a data set from that data in accordance with the designateddevice type. As shown in FIG. 6, upon selection of device type A, therelevant data for device type A is obtained from the master library 540to create a data set, which may include one or more configurationdatabases. In the embodiment shown in FIG. 6, three differentconfiguration datasets 1,2, and 3, identified by reference numerals 558,560 and 562, respectively, are created for device type A. The loadingtool 58 then communicates the device-specific configuration datasets558, 560 and 562 to a patient care device 564, which is, for example, atype A device and loads the datasets into the device to appropriatelyconfigure it. In one embodiment, patient care device 564 may be selectedand identified by a user via user interface 52 (FIG. 1). Alternatively,the configuration management system 42 may be configured to recognizeparticular patient care devices in the network by querying the deviceand determining an identification of the device. In one embodiment, theidentification of the device may comprise device type identification.

In one embodiment of the present invention, a plurality of patient caredevices are linked through a local area network (LAN) to a floor or unitserver as shown in FIG. 7. For example, in a neonatal intensive careunit (NICU) having an NICU server 610, a plurality of bedside patientcare devices 650, 652, 654 and 656 are connected through a LAN 620 tounit server 610. Similar network servers may be provided throughout thehospital, such as pediatrics 612, intensive care unit (ICU) 614, surgery(OR) 616 and oncology 618. Unit server 610 may contain the configurationdataset information for the various types of patient care devices forthat particular unit. The configuration datasets in patient care devices650, 652, 654, 656 could be updated periodically by downloading themfrom the unit server. Alternatively, the appropriate device-specificconfiguration dataset could be downloaded from the server or system 42as it is selected for use in patient care device 650, 652, 654 or 656.Still another alternative is to have a unit-or department-specificconfiguration dataset for the various types of devices that isautomatically downloaded into a patient care device 650, 652, 654, 656when the system is operatively connected to the department LAN. In anycase, having some or all of the configuration dataset information storedin the unit server 610,612,614,616,618 facilitates management andupdating of the databases. The configuration databases may also bestored in bedside CPUs which are situated in each private room,semi-private room, or ward area for monitoring or treating one or morepatients. U.S. Pat. No. 5,718,442 to Engleson et al., which isincorporated herein by reference in its entirety, describes a system forconnecting bedside medical devices to a hospital network, or network ofnetworks, that may be suitable for use with the present invention.

In yet another embodiment, a universal configuration database containingdatasets capable of configuring a device to operate in accordance withvarious behaviors depending on the use or location of the device mayalso be stored in the device. In this embodiment, for example, aninfusion pump may have a dataset for configuring the pump for use in theICU, in the pediatric ward, for delivery of oncology medications. Theinterface of the pump may allow a user to select a mode of operationfrom a menu of possible modes, which in actuality selects a datasetincorporating various ensembles of clinical and operating behaviors, orrule sets appropriate to the use for which the user is selecting themode of operation.

Non-Networked Embodiment

In yet another alternative embodiment of the present invention, patientcare devices and systems 44,46,48 (FIG. 1) are not directly connected tonetwork 30. Rather, information is sent to the devices or systemsindirectly over the network 30 using data input device 60, userinterface 54, auxiliary interface 62 or other communication means. Suchcommunication means include, but are not limited to, RS232 links, MIBsystems, IR links, WLANS, portable data assistants, memory cards,portable storage media or any other suitable communication means.Indirect communication can also be accomplished, for example, usingmodems with either the traditional phone system, voice over data or withcellular phones. In one example, a portable computer such as a personaldata assistant may be used to transfer the appropriate device-specificdatabase information and/or infusion instructions from systems 36 and 42to patient care devices and systems 44, 46, 48. The various possiblemeans of direct and indirect communication allow information to becontinuously or periodically transferred between the patient care deviceand other systems in network 30, such as, for example, hospitaladministration system 34, pharmacy information system 36, medicalconfiguration management system 42, and the like.

Referring again to FIG. 1, regardless of how patient care devices 44,46, 48 connect to or otherwise communicate with other systems in thehealthcare facility, in one embodiment of the present invention,information is transferred, at least occasionally, between the variousdepartments and systems within the facility such that functionality ofpatient care devices and systems 44, 46, 48 are altered by informationreceived from the other systems. Such a distributed, coordinated caresystem provides for efficient utilization of assets and improved qualityof patient care by maximizing integration and utility of informationfrom various sources in the system and by limiting opportunities forhuman error. As discussed above, one example of how patient care deviceand system 44, 46 or 48 may alter its personality based upon informationreceived from other sources is selection of a specific configurationdataset defining a particular, treatment location-specific (e.g. NICU,Pediatrics, ICU, Surgery, Oncology, etc.), operating behavior for thedevice. Similarly, prescription information, patient treatment history,drug incompatibilities, and the like from the pharmacy informationsystem 32 are utilized to configure and control clinical devices andsystems 44, 46, 48 and to minimize data entry errors.

By way of a non-limiting example, the use of the information and caremanagement system 28 according to the present invention is explained ingreater detail below by reference to procedures for configuring patientcare devices and systems 44, 46, 48 for providing a prescribed treatmentto a patient.

Most hospitals commonly have an established formulary of medicationswhich defines how the medications are typically dispensed. When apatient care management system according to the present invention isfirst installed, a hospital committee may be formed to determine howthat formulary would be applied to the patient care devices and systems44, 46, 48. The configuration definitions (such as, for example, byhospital unit such as ICU, NICU, Pediatrics, Oncology, Surgery, etc.)are agreed upon and the drugs and typical infusion protocols andguidelines are established. In addition, all out-of-limit, or guardrail, conditions are defined. A biomedical engineer or other qualifiedpersonnel then enters the information into the universal configurationdatabase management system via user interface 92 in order to customizethe universal configuration database 84 for the particular institution.As discussed previously, with use of the editing tool 86, the user mayedit entries that are common to different types of patient care devicesat the same time. Device-specific entries, such as those for deviceoperating characteristics, may be pre-entered by the manufacturer.Alternatively, the user may also enter these values into the universalconfiguration database 84. As the configuration datasets for differenttypes of patient care devices have been integrated into one universalconfiguration database 84, the user can more efficiently and accuratelyprovide standardized guidelines for use at the hospital. Alternatively,an institution may purchase, or otherwise be provided, with a universalconfiguration database, containing commonly used rule sets, ensembles,drug delivery schedules, out-of-limits events and the like, which may beused by the institution, or which may be modified by the institution asdesired.

The entries for the Communication Protocol 408 and Data Structure 410fields may either be entered into the library by the manufacturer and/orentered at the health care facility by qualified personnel, such as abiomedical engineer or other skilled technician, during customization ofthe universal configuration database. For example, the biomedical andinformation technology specialists at the health care facility typicallyhave access to device characteristics, including communicationprotocols, for each device used at the facility. During customization ofthe universal configuration database, the specialist may enter theCommunication Protocol 408 and Data Structure 410 data for the varioustypes of devices used at the facility. For different devices marketedand/or licensed by a single manufacturer, the communication informationfor each device may be entered into the universal configuration databaseat the manufacturer level, thus eliminating the need for the technicianto enter such information.

When all of the definitions are complete, then a configuration can bereleased for use in the institution's medical devices and systems. Forexample, infusion pumps at the institution may be configured, programmedor updated by transferring the device-specific configuration datasetsinto some or all of the institution's pumps. Transfer of theconfiguration dataset information typically occurs over communicationsystem 30. Alternatively, configuration datasets may bedownloaded/updated using removable media, portable computers, personaldata assistants, or any other appropriate means for transferringinformation to patient care devices and systems 44, 46, 48.

The Loading Tool 88 causes the appropriate device-specific configurationdatasets to be electronically loaded onto each of the target patientcare devices at the hospital. The Loading Tool 88 automatically providesselective downloading of modules and information from the common libraryfor each type of device as defined by the Device Type Module 100 or 550.

Assuring that the medication is being administered to the correctpatient is also provided by this system. Upon entering the hospitalevery patient is typically issued an identification number (patient ID)and an associated wrist band. Printed on the band or located within theband is the patient ID in text form and in coded form. Various optionsexist for the coded ID. For example, the band could utilize a bar code,a magnetic strip, or any other means of storing coded patientidentification information. The desired configuration database mightalso be recorded on the wrist band. For example, a child may have a bandwith an indicator that the pediatric configuration database is to beused.

The wrist band or ID device may also include a wireless device thatallows the ID device or band to be governed by an appropriate device atthe patient location to passively, if not automatically, identify thepatient. The patient's identity would then be provided, using eitherwired or wireless communication means, to whatever equipment at thepatient's location required it. Similar technology may be used inconjunction with medication labels, discussed in detail below.

The process steps involved in configuring a device to utilize aparticular configuration dataset according to one embodiment of thepresent invention are shown in FIG. 8. After power to device or system48 is turned on 700 and an internal systems check 704 is performed, thedevice displays on user interface 64 information pertaining to thecurrent patient and/or the current location 708. In one embodiment ofthe invention, this information is recalled from the last use of thedevice. Alternatively, the device location and or patient identificationmay be determined by information received through the communicationsystem 30 within the hospital. For example, referring to FIG. 7, adevice 650 connected over LAN 620 to a server in NICU 610 receivesinformation from the server that it should be located by Bed 1, and thata particular patient is scheduled to be in that bed. Accordingly, thedevice 650 utilizes that information as the default patient andlocation. Alternatively, device 650 automatically determines itslocation within the hospital by a sensor or other means of uniquelydetermining its location. A sensor is defined broadly herein as anydevice or process of sensing or detecting the location of a device,including, but not limited to, a network receptacle or port address, anetwork adapter, programmed location instructions, hospital recordsindicating location, an IR sensors or tags, RF sensors or tags, magneticsensors or tags, or any other means of detecting the location of adevice 650.

In step 712 the device queries the user whether the patient informationis correct. If the patient is new to the device, or if the informationis missing or incorrect, the user enters the patient ID in step 716.Patient ID is typically entered using input device 66, e.g., by scanninga patient's coded wristband including patient identification information. Alternatively, patient ID may be entered manually using a keyboard,keypad, or other interface device 64. If the current configurationdataset is missing or incorrect 720, the user is prompted to select theappropriate configuration dataset 724 such as, for example, by selectinga configuration dataset according to clinical location, patient,physician, and the like. Alternatively, the appropriate configurationdataset ID may scanned into the system from the patient's identificationband, or may be automatically retrieved from memory or from anotherlocation in communication system 30 once the patient identity, locationor other patient-specific information is entered into device or system48.

When a physician orders an IV, the order is typically first sent to thepharmacy (where it is entered into the hospital's pharmacy informationsystem 36). The order may either be written on a simple prescriptionslip or entered directly into the POE system 38 (FIG. 1). Most hospitalsinclude a pharmacy computer system capable of maintaining records ofmedications already given as well as those prescribed in the future.Most commercially available pharmacy systems allow for adverse druginteractions to be checked for as part of the process prescriptionentering/drug dispensing process.

According to a preferred embodiment of the present invention, after theorder is entered the prescription is prepared. If the drug is compoundedor sourced in the pharmacy, then the prescribed medication is preparedand placed in a container. Pharmacy information system 36 would thentranslate the infusion order from the hospital pharmacy software onto alabel with encoded message and accompanying text. The label preferablyincludes at least the following information: patient ID, infusionprotocol reference, infusion protocol deviations, or deltas, if any, andscheduled time of infusion. The label is affixed to the medicationcontainer before the prescription is transported to the unit nursingstation. Medications are preferably transported from the Pharmacy to thenurse's station by hospital personnel or contained within drugdispensing cabinets near the nurse's station. Alternatively, drugs maybe transported using a robotic system, such as a PYXIS system (PyxisCorporation, San Diego, Calif.). If the drug is to be distributed from aunit nursing station, then the same type of label may be printed at thestation and affixed to the drug container.

J At an appropriate time, the labeled medication container is then takento the patient's location. The bar code reader (or other data inputdevice, including passive devices designed to automatically querydevices associated with the various ID and medication labels) is used toscan the coded drug label, the patient's coded ID band and thecaregiver's ID badge, and optionally supplementary prescriptioninformation or medical device configuration instructions (includingconfiguration dataset ID) printed on the label or an accompanying order,or otherwise made available for entry or downloading into the medicaldevice or system once confirmation of the patient and medication iscompleted. The scanned information is stored in memory 62, while deviceor system 48 first compares the scanned data to ensure that the patientidentity corresponds to the patient information on the medication label,and that the prescription is being administered at the appropriate time.

After the correct patient, prescription and time are verified, device orsystem 48 recalls from the active configuration database the protocol orother program information identified on the container label. The defaultparameter values are adjusted by any delta information included in theprescription. The user is prompted to enter, using a touch pad, bar codereader, or any other appropriate means, any missing or incomplete data.Optionally, some data may be obtained automatically via communicationsystem 30 or from the appropriate department server based upon theentered patient IO, caregiver IO, user commands, etc. Once all requiredsettings have been entered, central unit 50 displays the values, eitherserially or in one or more groups, to the user for verification. Theconfiguration dataset is also accessed to check the entered infusionparameters according to the protocols, rule sets or other guidelines forthat configuration. If any incorrect or out of range entries aredetected, an alert may be activated to inform the operator. Once allinformation is entered and verified, interface unit 50 (FIG. 1) programsthe functional module(s) 52, 54, 56 or 58 to perform the prescribedtreatment.

It should be noted that the prescription label or other treatmentinstructions may identify multiple drug delivery schedules and otherinstructions. The multiple drug delivery schedules (or a single complexdrug delivery schedule) may define a plurality of operations to beperformed by device or system 48. For example, the prescription label orprescription order could identify a multichannel coordinated infusiondrug delivery schedule involving multiple channels and infusionsolutions. Additionally, the same order may identify a delivery schedulefor (or detail instructions for) programming a functional module orauxiliary device to monitor the patient physiological parameters, suchas a blood pressure, heart rate, O2 saturation, respiratory rate, andthe like. Interface unit 50 monitors the measured parameters and,depending upon active rule sets and other configuration instructions,can modify infusion parameters based upon signals received from thephysiological monitors. Such feedback systems may be useful fortitration of drugs, to control anesthesia, or to regulate bloodpressure.

While several particular forms of the invention have been illustratedand described, it will be apparent that various modifications can bemade without departing from the spirit and scope of the invention.

We claim:
 1. A universal configuration database (UCDB), comprising: aprotocol associated with a medication; an institutionally establishedguideline associated with one of a plurality of treatment locations,wherein the guideline comprises a maximum dose rate; a plurality offirst data elements each comprising a device operating characteristicassociated with one of the plurality of device types; a plurality ofsecond data elements each comprising device communication informationassociated with one of the plurality of device types; and a device typemodule comprising a plurality of fields respectively associated with oneof the plurality of device types, each field comprising at least onereference link to at least one of the data elements associated with thedevice type associated with the field; wherein the first and seconddatasets created from the UCDB respectively configure a first devicetype and a second device type to deliver the medication according to theprotocol and the guideline, wherein delivery of the medication by thefirst device type when loaded with the first dataset is equivalent todelivery of the medication by the second device type when loaded withthe second dataset, and wherein the second device type will not deliverthe medication according to the protocol and the guideline when thesecond device type is loaded with the first dataset.